With the phenomenal growth of networks, today's developers must "think distributed". Applications--and even parts of applications--must be able to migrate easily to a wide variety of computer systems, a wide variety of hardware architectures, and a wide variety of operating system architectures. They must operate with a plethora of graphical user interfaces. Clearly, if applications must be able to execute anywhere on the network without a priori knowledge of the hardware and software platform on which it will run, the binary distribution problem quickly becomes unmanageable. To solve this problem, software must become architecture-neutral and portable. Finally, reliability is at a high premium in the distributed world--code from anywhere on the network should work robustly without low probabilities of creating "crashes" in applications importing code fragments.
The solution that the Java language system adopts to solve the binary distribution problem is a "binary code format" that's independent of hardware architectures and operating system and window system interfaces. This file format is architecture-neutral. If the Java run-time system is made available on a given hardware and software platform, Java language applications can then execute on many different processors and operating system architectures without the need to port them.
Byte Codes
The Java language compiler doesn't generate "machine code" in the sense of native hardware instructions. Rather, the Java language compiler generates byte codes--a high-level, machine-independent "machine code" for a hypothetical machine that is implemented by the Java interpreter and run-time system. One of the early examples of this approach was the UCSD P System, which was immensely popular in the middle 1970s and early 1980s.
The architecture-neutral approach is useful not only for network-based applications, but also for single system software distribution. In today's personal computer market, application writers have to produce versions of their applications that are compatible with the IBM PC, Apple Macintosh, and 57 flavors of workstation architectures in the fragmented UNIX marketplace. With the PC market (through Windows/NT) diversifying into many CPU architectures, and Apple moving full steam from the 68000 to the PowerPC, production of software to run on all platforms becomes almost impossible. Using the Java language, the same version of your application can run on all platforms.
The Java language byte codes are designed to be both easy to interpret on any machine and easy to dynamically translate into native machine code if required.
The primary benefit of using the interpreted byte code approach is that compiled Java language programs are portable to any system on which the Java interpreter and run-time system have been implemented.
The architecture-neutral aspect discussed above is one major step towards being portable, but there's more to it than that. C and C++ both suffer from the defect of designating many fundamental data types as "implementation dependent". Programmers labor to ensure programs are portable across architectures by programming to a lowest common denominator.
The Java language eliminates this issue by defining standard behavior that will apply to the data types across all platforms. The sizes of the Java language's primitive data types are specified, as is the behavior of arithmetic on them. Here are the data types:
byte 8-bit two's complement
short 16-bit two's complement
int 32-bit two's complement
long 64-bit two's complement
float 32-bit IEEE 754 floating point
double 64-bit IEEE 754 floating point
char 16-bit Unicode character
Note that the Java language has no unsigned data types.
The data types and sizes described above are standard across all implementations of the Java language environment. These choices are reasonable given current microprocessor architectures because essentially all of the central processor architectures in use today share these characteristics That is, most modern processors can support two's complement arithmetic in 8-bit to 64-bit integer formats, and most support single- and double-precision floating point.
The libraries that are part of the Java language run-time system define portable interfaces. For example, there is an abstract Window class and implementations of it for UNIX, Windows, and Macintosh.
The Java language environment itself is readily portable to new architectures and operating systems. The Java compiler is itself written in the Java language. The Java run-time system is written in ANSI C with a clean portability boundary which is essentially POSIX-compliant. There are no "implementation dependent" notes in the Java language specification.
The Java language is intended for developing software that must be robust, highly reliable, and secure, in a variety of ways. The Java language places a lot of emphasis on early checking for possible problems, later dynamic (run-time) checking, and eliminating error prone situations.
Strict Compile Time Checking
The Java compiler employs extensive and stringent compile-time checking so that syntax-related errors can be detected early, before a program is deployed into service.
One of the advantages of a strongly typed language (like C++) is that it allows extensive compile-time checking so bugs can be found early. Unfortunately, C++ inherits a number of loopholes in this checking from C, which is relatively lax (the major issue is method/procedure declarations). The Java language requires declarations and does not support C-style implicit declarations.
Many of the stringent compile-time checks are carried over to the run-time, to check consistency at run-time, and to provide greater flexibility. The linker understands the type system and repeats many of the type checks done by the compiler, to guard against version mismatch problems.
The single biggest difference between the Java language and C/C++ is that the Java language's memory model eliminates the possibility of overwriting memory and corrupting data. Instead of pointer arithmetic, the Java language has true arrays, which means that the interpreter can check array and string indexes. In addition, a programmer can't write code that turns an arbitrary integer into a pointer by casting.
Garbage collection makes the programmer's job vastly easier. With the burden of memory management taken off the programmer's shoulders, storage allocation errors go away.
While the Java language doesn't pretend to completely remove the software quality assurance problem, removal of entire classes of programming errors considerably eases the job of testing and quality assurance.
A Major Benefit--Fast and Fearless Prototyping
Very dynamic languages like Lisp, TCL, and SmallTalk are often used for prototyping. One of the reasons for their success at this is that they are very robust--you don't have to worry about freeing or corrupting memory.
Programmers can be relatively fearless about dealing with memory when programming in the Java language because they don't have to worry about it getting messed up.
Another reason commonly given that languages like Lisp, TCL, and SmallTalk are good for prototyping is that they don't require you to pin down decisions early on--these languages are semantically rich.
The Java language has exactly the opposite property--it forces you to make explicit choices. Along with these choices come a lot of assistance--you can write method invocations and, if you get something wrong, you get told about it at compile time. You don't have to worry about method invocation error.
The Java language--an architecture-neutral and portable programming language--provides an attractive and simple solution to the problem of distributing your applications across heterogeneous network-based computing platforms. In addition, the simplicity and robustness of the underlying Java language results in higher quality reliable applications in which users can have a high level of confidence.
